1. Field
Embodiments generally relate to testing frameworks, and particularly towards script testing.
2. Background
Unit testing is a method by which individual units of source code (or script) are tested to determine if they are fit for use. In one example, a unit may be a smallest testable part of an application. In another example, a unit may be an individual function or procedure. Unit tests are typically written and run by software developers to ensure that code behaves as intended when executed. Unit tests are generally run using testing frameworks. Testing frameworks may be used test a web page that includes script. Such testing of the web page may enable developers to determine if, for example, script in the web page loads and executes appropriately.
JsUnit is an example of a publicly available client-side (or browser-side) unit testing framework for JavaScript. A unit test using the JsUnit framework determines and retrieves the necessary files (or “dependencies”) containing JavaScript code for a test to execute properly. In a first technique to load code dependencies into a browser for test, the JsUnit testing framework can place a script tag (e.g., “<script>”) in the Hyper Text Markup Language (HTML) portion of a test page to reference the dependencies. In a second technique, the JsUnit testing framework can dynamically add a script tag referencing dependencies using loaded test code. In a third technique, the JsUnit testing framework can dynamically read dependencies from a server (e.g., using an iFrame or XML HttpRequest).
Each of these techniques require server, network and browser resources, resulting in a distinctly longer time for test setup. When the number of tests become non-trivial, test setup time increases due to the expenditure of resources, in browser and server, necessary to load test dependencies. Additionally, because of reduced computational and network resources, actual test execution time can increase resulting in inappropriate test failures. The second and third techniques noted above also expend browser resources which can result in slower test execution and occasionally even complete browser failure.
Some testing frameworks may cache dependencies at a server, or rely on a browser's built-in cache to store the dependencies. Server caching only reduces the time and resources necessary to serve the dependencies to the browser, still requiring a network connection and browser resources. Furthermore, because a browser's cache is inconsistent, caching of dependencies in the browser's built-in cache does not ensure that a script test will run appropriately and without error.